Notes from various man pages and internet searches:

When VTIME is greater than 0 it enables the timer, but there are two different types of timers, depending on whether VMIN is 0 or not.

If VTIME and VMIN are both greater than 0:

• The timer is an 'inter-byte timer' activated when the first byte is received.
• It is then reset whenever a new byte is received, and will timeout (count in tenths of seconds with a max of 25.5 sec) if there is the specified time without another byte being received.
• A call to read() will block until at least 1 byte is received, unless a signal interrupts.
• If data is buffered when read() is called, and the number of bytes is equal or greater than VMIN, the read() call will return immediately with existing data.

When VTIME is greater than 0 and VMIN is 0:

• The timer is a *read* *timer* _activated_assoonastheread() _function_ _is_ _called_.
• If no byte is received in the specified time, there will be a timeout and the read() call will return 0, with no data.
• Since VMIN is 0, the receipt of a single byte will satisfy the read() call, and cause a return. If there is data in the buffer when read() is called, read() will immediately return with existing data.

If VTIME is 0, the timer is disabled. If VMIN is also 0:

• A call to read() will _return_ _immediately_.
• The minimum of either the number of bytes requested or the number of bytes currently available will be returned.
• If no characters are available, read() returns 0, with no data.

If VTIME is 0 and VMIN is greater than 0:

• The timer is disabled, but a call to read() will _block__indefinitely_ until either data is received or a signal interrupts.
• When VMIN bytes have been received, the read() function will return.
• If there is data in the buffer when read() is called, and the number of bytes is equal to or greater than VMIN, the read() call will return immediately with existing data.

Okay, now given that you want to read one or more characters and have a timeout, the question is do you actually want an inter-byte timer, or a read timer?

If you set both VTIME and VMIN to 1, for example, you'll have an inter-byte timer... and calls to read() can *block* *forever* if no data at all is received.

If you want a read timer, set VMIN to 0 and VTIME to 1, and then the call to read() will always return, with or without data. If there is no data available, read() will return 0, if data is available it will return the number of data bytes retrieved.

All of the above assumes that the O_NONBLOCK attribute is not set. And for any of the above if the call to read() is interrupted by a signal, read() will return -1, and the error code will be EINTR. (More discussion about this below.)

 ----------------------------------------------------

When the ICANON bit is turned off, a "raw mode" is selected which changes the interpretation of these values. These are used to guide the line-driver code in its decision on allowing the read() system call to return. We'll try to explain them in some detail. Function-key processingOn a regular keyboard, most keys send just one byte each, but almost all keyboards have special keys that send asequence of charactersat a time. Examples (from an ANSI keyboard)ESC [ A      up arrowESC [ 5 ~    page upESC [ 18 ~   F7and so on.From a strictly "string recognition" point of view, it's easy enough to translate "ESC [ A" into "up arrow" inside a program, but how does it tell the difference between "user typed up-arrow" and "user typed the ESCAPE key"? The difference istiming. If the ESCAPE isimmediatelyfollowed by the rest of the expected sequence, then it's a function key: otherwise it's just a plain ESCAPE.Efficient highspeed inputWhen a communications program (such as fax software) is reading from a modem, the data stream is arriving at a relatively high rate. Doing single-character-at-a-time input would be extremely inefficient, given that eachread()involves a system call and an operating system context switch. We'd instead like to read in larger chunk if it's available for us, but still know how to recognize timeouts (which usually indicate error conditions).Capturing occasional, low-volume dataWhen writing software that monitored a temperature sensor via a serial line, we expected to receive a short (10-20 bytes) message every second. This message arrived as a single burst, and once the first character of the message was received, weknewthat the others were right behind it and would be completely received in about 100 milliseconds.The message format did not have strong delimiters, so if we used a naïve read of so many bytes, we'd run the risk of reading an entire message but blocking until a few more bytesof the next messagewere read to fill our request. This could lead to getting "out of sync" with the sensor.By settingVMIN/VTIMEproperly, we were able to insure that that we could efficiently capture all the data sent in one burst without risk of inter-message overlap.We'll note that some of these timeout issues can be partly addressed by the use of signals and alarms, but this is really a substandard solution: signals and I/O are hard to get right (especially in a portable manner), and we very strongly prefer using the features of the line-discipline code as they were intended. Signals suck.

When does read() return?

The termios settings are actually handled in the kernel, and the ones we're interested in are in the line discipline code. This sits above the "device driver", and this is consistent with our applying termios to both serial and network I/O (which obviously use different underlying hardware).

All of the VMIN and VTIME areas involve one question: When does the line driver allow read() to return?
With a "regular file", the operating system returns from the read() system call when either the user buffer is full, or when the end of file has been reached - this decision is easy and automatic.

But when the driver is reading from a terminal line, the "Are we done?" question can be asked over and over for each character that arrives. This question is resolved by setting VMIN/VTIME.

Using our temperature-sensor example, we'll list the requirements that inform our design:

• We normally read up to 20 bytes as a "message"
• Individual messages have their bytes all sent together
• No background processing required; while waiting for input, we're happy to block indefinitely waiting for something to happen

The last requirement means that we have no overall timeout, but we do have an intercharacter timeout. This is the key functionality provided by the line driver. Let's be specific.

When waiting for input, the driver returns when: VTIMEtenths of a second elapsesbetweenbytesAn internal timer is started when a character arrives, and it counts up in tenths of a second units. It's reset whenever new data arrives, so rapidly-arriving data never gives the intercharacter timer a chance to count very high.It's only after thelastcharacter of a burst — when the line is quiet — that the timer really gets counting. When it reachesVTIMEtenths, the user's request has been satisfied and theread()returns.This provides exactly the behavior we want when dealing with bursty data: collect data while it's arriving rapidly, but when it calms down, give us what you got.VMINcharacters have been received, with no more data availableAt first this appears duplicative to thenbytesparameter to theread()system call, but it's not quite the same thing.The serial driver maintains an input queue of data received but not transferred to the user — clearly data can arrive even when we're not asking for it — and this is always first copied to the user's buffer on aread()without having to wait for anything.But if we do end up blocking for I/O (because the kernel's input queue is empty), thenVMINkicks in: When that many bytes have been received, theread()request returns that data. In this respect we can think of thenbytesparameter as being the amount of data wehopeto get, but we'll settle forVMIN.The user's requested number of bytes has been satisfiedThis rule trumps all the others: there is no circumstance where the system will providemoredata than was actually asked for by the user. If the user asks for (say) ten bytes in theread()system call, and that much data is already waiting in the kernel's input queue, then it's returned to the caller immediately and without havingVMINandVTIMEparticipate in any way.These are certainly confusing to one who is new to termios, but it's not really poorly defined Instead, they solve problems that are not obvious to the newcomer. It's only when one is actually dealing with terminal I/O and running into issues of either performance or timing that one really must dig in.

VMIN and VTIME defined

VMIN is a character count ranging from 0 to 255 characters, and VTIME is time measured in 0.1 second intervals, (0 to 25.5 seconds). The value of "zero" is special to both of these parameters, and this suggests four combinations that we'll discuss below. In every case, the question is when a read() system call is satisfied, and this is our prototype call: int n = read(fd, buffer, nbytes);
Keep in mind that the tty driver maintains an input queue of bytes already read from the serial line and not passed to the user, so not every read() call waits for actual I/O - the read may very well be satisfied directly from the input queue. VMIN = 0 and VTIME = 0This is a completely non-blocking read - the call is satisfied immediately directly from the driver's input queue. If data are available, it's transferred to the caller's buffer up to nbytes and returned. Otherwise zero is immediately returned to indicate "no data". We'll note that this is "polling" of the serial port, and it's almost always a bad idea. If done repeatedly, it can consume enormous amounts of processor time and is highly inefficient. Don't use this mode unless you really, really know what you're doing.VMIN = 0 and VTIME > 0This is a pure timed read. If data are available in the input queue, it's transferred to the caller's buffer up to a maximum of nbytes, and returned immediately to the caller. Otherwise the driver blocks until data arrives, or when VTIME tenths expire from the start of the call. If the timer expires without data, zero is returned. A single byte is sufficient to satisfy this read call, but if more is available in the input queue, it's returned to the caller. Note that this is anoveralltimer, not anintercharacterone.VMIN > 0 and VTIME > 0Aread()is satisfied when either VMIN characters have been transferred to the caller's buffer, or when VTIME tenths expire between characters. Since this timer is not started until the first character arrives, this call can block indefinitely if the serial line is idle. This is the most common mode of operation, and we consider VTIME to be anintercharactertimeout, not anoverallone. This call should never return zero bytes read.VMIN > 0 and VTIME = 0This is a counted read that is satisfied only when at least VMIN characters have been transferred to the caller's buffer - there is no timing component involved. This read can be satisfied from the driver's input queue (where the call could return immediately), or by waiting for new data to arrive: in this respect the call could block indefinitely. We believe that it's undefined behavior if nbytes is less then VMIN.

---------------------------------------

 http://www.gnu.org/software/libc/manual/html_mono/libc.html\\

17.4.4 Input Modes

This section describes the terminal attribute flags that control fairly low-level aspects of input processing: handling of parity errors, break signals, flow control, and <RET> and <LFD> characters.

All of these flags are bits in the c_iflag member of the struct termios structure. The member is an integer, and you change flags using the operators &, | and ^. Don't try to specify the entire value for c_iflag---instead, change only specific flags and leave the rest untouched (see Setting Modes). — Macro: tcflag_t INPCK
If this bit is set, input parity checking is enabled. If it is not set, no checking at all is done for parity errors on input; the characters are simply passed through to the application.

Parity checking on input processing is independent of whether parity detection and generation on the underlying terminal hardware is enabled; see Control Modes. For example, you could clear the INPCK input mode flag and set the PARENB control mode flag to ignore parity errors on input, but still generate parity on output.

If this bit is set, what happens when a parity error is detected depends on whether the IGNPAR or PARMRK bits are set. If neither of these bits are set, a byte with a parity error is passed to the application as a '\0' character. — Macro: tcflag_t IGNPAR
If this bit is set, any byte with a framing or parity error is ignored. This is only useful if INPCK is also set.
— Macro: tcflag_t PARMRK
If this bit is set, input bytes with parity or framing errors are marked when passed to the program. This bit is meaningful only when INPCK is set and IGNPAR is not set.

The way erroneous bytes are marked is with two preceding bytes, 377 and 0. Thus, the program actually reads three bytes for one erroneous byte received from the terminal.

If a valid byte has the value 0377, and ISTRIP (see below) is not set, the program might confuse it with the prefix that marks a parity error. So a valid byte 0377 is passed to the program as two bytes, 0377 0377, in this case.
— Macro: tcflag_t ISTRIP
If this bit is set, valid input bytes are stripped to seven bits; otherwise, all eight bits are available for programs to read.
— Macro: tcflag_t IGNBRK
If this bit is set, break conditions are ignored.

A break condition is defined in the context of asynchronous serial data transmission as a series of zero-value bits longer than a single byte.
— Macro: tcflag_t BRKINT
If this bit is set and IGNBRK is not set, a break condition clears the terminal input and output queues and raises a SIGINT signal for the foreground process group associated with the terminal.

If neither BRKINT nor IGNBRK are set, a break condition is passed to the application as a single '\0' character if PARMRK is not set, or otherwise as a three-character sequence '\377', '\0', '\0'.
— Macro: tcflag_t IGNCR
If this bit is set, carriage return characters ('\r') are discarded on input. Discarding carriage return may be useful on terminals that send both carriage return and linefeed when you type the <RET> key.
— Macro: tcflag_t ICRNL
If this bit is set and IGNCR is not set, carriage return characters ('\r') received as input are passed to the application as newline characters ('\n').
— Macro: tcflag_t INLCR
If this bit is set, newline characters ('\n') received as input are passed to the application as carriage return characters ('\r').
— Macro: tcflag_t IXOFF
If this bit is set, start/stop control on input is enabled. In other words, the computer sends STOP and START characters as necessary to prevent input from coming in faster than programs are reading it. The idea is that the actual terminal hardware that is generating the input data responds to a STOP character by suspending transmission, and to a START character by resuming transmission. See Start/Stop Characters.
— Macro: tcflag_t IXON
If this bit is set, start/stop control on output is enabled. In other words, if the computer receives a STOP character, it suspends output until a START character is received. In this case, the STOP and START characters are never passed to the application program. If this bit is not set, then START and STOP can be read as ordinary characters. See Start/Stop Characters.
— Macro: tcflag_t IXANY
If this bit is set, any input character restarts output when output has been suspended with the STOP character. Otherwise, only the START character restarts output.

This is a BSD extension; it exists only on BSD systems and the GNU system.
— Macro: tcflag_t IMAXBEL
If this bit is set, then filling up the terminal input buffer sends a BEL character (code 007) to the terminal to ring the bell.

This is a BSD extension.

17.4.5 Output Modes

This section describes the terminal flags and fields that control how output characters are translated and padded for display. All of these are contained in the c_oflag member of the struct termios structure.

The c_oflag member itself is an integer, and you change the flags and fields using the operators &, |, and ^. Don't try to specify the entire value for c_oflag---instead, change only specific flags and leave the rest untouched (see Setting Modes). — Macro: tcflag_t OPOST
If this bit is set, output data is processed in some unspecified way so that it is displayed appropriately on the terminal device. This typically includes mapping newline characters ('\n') onto carriage return and linefeed pairs.

If this bit isn't set, the characters are transmitted as-is.
The following three bits are BSD features, and they exist only BSD systems and the GNU system. They are effective only if OPOST is set. — Macro: tcflag_t ONLCR
If this bit is set, convert the newline character on output into a pair of characters, carriage return followed by linefeed. — Macro: tcflag_t OXTABS
If this bit is set, convert tab characters on output into the appropriate number of spaces to emulate a tab stop every eight columns.
— Macro: tcflag_t ONOEOT
If this bit is set, discard C-d characters (code 004) on output. These characters cause many dial-up terminals to disconnect.

17.4.6 Control Modes

This section describes the terminal flags and fields that control parameters usually associated with asynchronous serial data transmission. These flags may not make sense for other kinds of terminal ports (such as a network connection pseudo-terminal). All of these are contained in the c_cflag member of the struct termios structure.

The c_cflag member itself is an integer, and you change the flags and fields using the operators &, |, and ^. Don't try to specify the entire value for c_cflag---instead, change only specific flags and leave the rest untouched (see Setting Modes). — Macro: tcflag_t CLOCAL
If this bit is set, it indicates that the terminal is connected "locally" and that the modem status lines (such as carrier detect) should be ignored. On many systems if this bit is not set and you call open without the O_NONBLOCK flag set, open blocks until a modem connection is established.

If this bit is not set and a modem disconnect is detected, a SIGHUP signal is sent to the controlling process group for the terminal (if it has one). Normally, this causes the process to exit; see Signal Handling. Reading from the terminal after a disconnect causes an end-of-file condition, and writing causes an EIO error to be returned. The terminal device must be closed and reopened to clear the condition. — Macro: tcflag_t HUPCL
If this bit is set, a modem disconnect is generated when all processes that have the terminal device open have either closed the file or exited.
— Macro: tcflag_t CREAD
If this bit is set, input can be read from the terminal. Otherwise, input is discarded when it arrives.
— Macro: tcflag_t CSTOPB
If this bit is set, two stop bits are used. Otherwise, only one stop bit is used.
— Macro: tcflag_t PARENB
If this bit is set, generation and detection of a parity bit are enabled. See Input Modes, for information on how input parity errors are handled.

If this bit is not set, no parity bit is added to output characters, and input characters are not checked for correct parity.
— Macro: tcflag_t PARODD
This bit is only useful if PARENB is set. If PARODD is set, odd parity is used, otherwise even parity is used.
The control mode flags also includes a field for the number of bits per character. You can use the CSIZE macro as a mask to extract the value, like this: settings.c_cflag & CSIZE. — Macro: tcflag_t CSIZE
This is a mask for the number of bits per character. — Macro: tcflag_t CS5
This specifies five bits per byte.
— Macro: tcflag_t CS6
This specifies six bits per byte.
— Macro: tcflag_t CS7
This specifies seven bits per byte.
— Macro: tcflag_t CS8
This specifies eight bits per byte.
The following four bits are BSD extensions; this exist only on BSD systems and the GNU system. — Macro: tcflag_t CCTS_OFLOW
If this bit is set, enable flow control of output based on the CTS wire (RS232 protocol). — Macro: tcflag_t CRTS_IFLOW
If this bit is set, enable flow control of input based on the RTS wire (RS232 protocol).
— Macro: tcflag_t MDMBUF
If this bit is set, enable carrier-based flow control of output.
— Macro: tcflag_t CIGNORE
If this bit is set, it says to ignore the control modes and line speed values entirely. This is only meaningful in a call to tcsetattr.

The c_cflag member and the line speed values returned by cfgetispeed and cfgetospeed will be unaffected by the call. CIGNORE is useful if you want to set all the software modes in the other members, but leave the hardware details in c_cflag unchanged. (This is how the TCSASOFT flag to tcsettattr works.)

This bit is never set in the structure filled in by tcgetattr.

17.4.7 Local Modes

This section describes the flags for the c_lflag member of the struct termios structure. These flags generally control higher-level aspects of input processing than the input modes flags described in Input Modes, such as echoing, signals, and the choice of canonical or noncanonical input.

The c_lflag member itself is an integer, and you change the flags and fields using the operators &, |, and ^. Don't try to specify the entire value for c_lflag---instead, change only specific flags and leave the rest untouched (see Setting Modes). — Macro: tcflag_t ICANON
This bit, if set, enables canonical input processing mode. Otherwise, input is processed in noncanonical mode. See Canonical or Not. — Macro: tcflag_t ECHO
If this bit is set, echoing of input characters back to the terminal is enabled.
— Macro: tcflag_t ECHOE
If this bit is set, echoing indicates erasure of input with the ERASE character by erasing the last character in the current line from the screen. Otherwise, the character erased is re-echoed to show what has happened (suitable for a printing terminal).

This bit only controls the display behavior; the ICANON bit by itself controls actual recognition of the ERASE character and erasure of input, without which ECHOE is simply irrelevant.
— Macro: tcflag_t ECHOPRT
This bit is like ECHOE, enables display of the ERASE character in a way that is geared to a hardcopy terminal. When you type the ERASE character, a `\' character is printed followed by the first character erased. Typing the ERASE character again just prints the next character erased. Then, the next time you type a normal character, a `/' character is printed before the character echoes.

This is a BSD extension, and exists only in BSD systems and the GNU system.
— Macro: tcflag_t ECHOK
This bit enables special display of the KILL character by moving to a new line after echoing the KILL character normally. The behavior of ECHOKE (below) is nicer to look at.

If this bit is not set, the KILL character echoes just as it would if it were not the KILL character. Then it is up to the user to remember that the KILL character has erased the preceding input; there is no indication of this on the screen.

This bit only controls the display behavior; the ICANON bit by itself controls actual recognition of the KILL character and erasure of input, without which ECHOK is simply irrelevant.
— Macro: tcflag_t ECHOKE
This bit is similar to ECHOK. It enables special display of the KILL character by erasing on the screen the entire line that has been killed. This is a BSD extension, and exists only in BSD systems and the GNU system.
— Macro: tcflag_t ECHONL
If this bit is set and the ICANON bit is also set, then the newline ('\n') character is echoed even if the ECHO bit is not set.
— Macro: tcflag_t ECHOCTL
If this bit is set and the ECHO bit is also set, echo control characters with `^' followed by the corresponding text character. Thus, control-A echoes as `^A'. This is usually the preferred mode for interactive input, because echoing a control character back to the terminal could have some undesired effect on the terminal.

This is a BSD extension, and exists only in BSD systems and the GNU system.
— Macro: tcflag_t ISIG
This bit controls whether the INTR, QUIT, and SUSP characters are recognized. The functions associated with these characters are performed if and only if this bit is set. Being in canonical or noncanonical input mode has no affect on the interpretation of these characters.

You should use caution when disabling recognition of these characters. Programs that cannot be interrupted interactively are very user-unfriendly. If you clear this bit, your program should provide some alternate interface that allows the user to interactively send the signals associated with these characters, or to escape from the program. See Signal Characters.
— Macro: tcflag_t IEXTEN
POSIX.1 gives IEXTEN implementation-defined meaning, so you cannot rely on this interpretation on all systems.

On BSD systems and the GNU system, it enables the LNEXT and DISCARD characters. See Other Special.
— Macro: tcflag_t NOFLSH
Normally, the INTR, QUIT, and SUSP characters cause input and output queues for the terminal to be cleared. If this bit is set, the queues are not cleared.
— Macro: tcflag_t TOSTOP
If this bit is set and the system supports job control, then SIGTTOU signals are generated by background processes that attempt to write to the terminal. See Access to the Terminal.
The following bits are BSD extensions; they exist only in BSD systems and the GNU system. — Macro: tcflag_t ALTWERASE
This bit determines how far the WERASE character should erase. The WERASE character erases back to the beginning of a word; the question is, where do words begin?

If this bit is clear, then the beginning of a word is a nonwhitespace character following a whitespace character. If the bit is set, then the beginning of a word is an alphanumeric character or underscore following a character which is none of those.

See Editing Characters, for more information about the WERASE character. — Macro: tcflag_t FLUSHO
This is the bit that toggles when the user types the DISCARD character. While this bit is set, all output is discarded. See Other Special.
— Macro: tcflag_t NOKERNINFO
Setting this bit disables handling of the STATUS character. See Other Special.
— Macro: tcflag_t PENDIN
If this bit is set, it indicates that there is a line of input that needs to be reprinted. Typing the REPRINT character sets this bit; the bit remains set until reprinting is finished. See Editing Characters.

17.4.10 Noncanonical Input

In noncanonical input mode, the special editing characters such as ERASE and KILL are ignored. The system facilities for the user to edit input are disabled in noncanonical mode, so that all input characters (unless they are special for signal or flow-control purposes) are passed to the application program exactly as typed. It is up to the application program to give the user ways to edit the input, if appropriate.

Noncanonical mode offers special parameters called MIN and TIME for controlling whether and how long to wait for input to be available. You can even use them to avoid ever waiting---to return immediately with whatever input is available, or with no input.

The MIN and TIME are stored in elements of the c_cc array, which is a member of the struct termios structure. Each element of this array has a particular role, and each element has a symbolic constant that stands for the index of that element. VMIN and VMAX are the names for the indices in the array of the MIN and TIME slots. — Macro: int VMIN
This is the subscript for the MIN slot in the c_cc array. Thus, termios.c_ccVMIN is the value itself.

The MIN slot is only meaningful in noncanonical input mode; it specifies the minimum number of bytes that must be available in the input queue in order for read to return. — Macro: int VTIME
This is the subscript for the TIME slot in the c_cc array. Thus, termios.c_ccVTIME is the value itself.

The TIME slot is only meaningful in noncanonical input mode; it specifies how long to wait for input before returning, in units of 0.1 seconds.
The MIN and TIME values interact to determine the criterion for when read should return; their precise meanings depend on which of them are nonzero. There are four possible cases:

• Both TIME and MIN are nonzero.

In this case, TIME specifies how long to wait after each input character to see if more input arrives. After the first character received, read keeps waiting until either MIN bytes have arrived in all, or TIME elapses with no further input.

read always blocks until the first character arrives, even if TIME elapses first. read can return more than MIN characters if more than MIN happen to be in the queue. Both MIN and TIME are zero. In this case, read always returns immediately with as many characters as are available in the queue, up to the number requested. If no input is immediately available, read returns a value of zero.
MIN is zero but TIME has a nonzero value. In this case, read waits for time TIME for input to become available; the availability of a single byte is enough to satisfy the read request and cause read to return. When it returns, it returns as many characters as are available, up to the number requested. If no input is available before the timer expires, read returns a value of zero.
TIME is zero but MIN has a nonzero value. In this case, read waits until at least MIN bytes are available in the queue. At that time, read returns as many characters as are available, up to the number requested. read can return more than MIN characters if more than MIN happen to be in the queue. What happens if MIN is 50 and you ask to read just 10 bytes? Normally, read waits until there are 50 bytes in the buffer (or, more generally, the wait condition described above is satisfied), and then reads 10 of them, leaving the other 40 buffered in the operating system for a subsequent call to read.

Portability note: On some systems, the MIN and TIME slots are actually the same as the EOF and EOL slots. This causes no serious problem because the MIN and TIME slots are used only in noncanonical input and the EOF and EOL slots are used only in canonical input, but it isn't very clean. The GNU library allocates separate slots for these uses. — Function: void cfmakeraw (struct termios *termios-p)
This function provides an easy way to set up *termios-p for what has traditionally been called "raw mode" in BSD. This uses noncanonical input, and turns off most processing to give an unmodified channel to the terminal.

It does exactly this: termios-p->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP

---------------------------------------------------------------------------------

IOCTL's: Buffer count and flushing

FIONREAD int *argpGetthenumber ofbytesintheinput buffer.TIOCINQ int *argpSame as FIONREAD.TIOCOUTQ int *argpGetthenumber ofbytesintheoutput buffer.TCFLSH intargEquivalenttotcflush(fd, arg).
Seetcflush(3)fortheargument values TCIFLUSH, TCOFLUSH, TCIOFLUSH.